What is initdir
~~~~~~~~~~~~~~~
Conventional inittab uses one line per entry (initrec, or in other words
child process). Initdir is about using one file per entry,
and a directory(-ies) in place of, or in addition to inittab.


Why initdir?
~~~~~~~~~~~~
Having one-file-per-initrec as opposed to one-line-per-initrec
simplifies distro package management. Each package supplies its
own initrec file, installing it in some pre-determined directory.
With one-line-per-initrec approach, this would require modifying
inittab on install *and* uninstall, probably via install/uninstall
scripts.


Why single initdir?
~~~~~~~~~~~~~~~~~~~
There has been some oscillation between having a single, pre-configure
initdir (/etc/initdir, akin to /etc/inittab) and allowing include-like
directives in inittab. With two-way initpass, the decision has been
shifted to a single initdir.

Rationale: initdir entries are inherently unordered and do not mix well
with ordered inittab entries. Before two-way initpass was implemented,
it made sense to have allow w-type entries to follow services, so that
they would be started after all services have been killed.
Two-way initpass ensures it's always the case.

Even with current implementation, initdir entries look somewhat out of place.
Which bring the following problem:


Initdir vs preprocessing inittab
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Instead of having initdir code in init itself, it's equally possible
to move it out, making inittab dynamically generated from a static
section and files in initdir.

Stand-alone preprocessor would definitely allow more stuff
to be implemented without increasing resident init footprint significantly.
But for now I see it as unnecessary complication.
Built-in initdir support takes about 1kB, and provides all features I'd like
it to provide.

Initdir support is also easy to compile-out (#undef INITDIR in config.h)
for people who do not need it, including those trying to do pre-processing.


Service activation
~~~~~~~~~~~~~~~~~~
Installing files means init will try to start the services upon
the next config re-read as there is no simple way to install them
disabled at this moment.

Installing disabled services and then activating them requires
non-trivial activation routine; telinit is not well-fit for this
purpose, and the idea of using telinit to modify service files
does not sound right. This calls for another tool to control
service files on disk.

And once there's another tool on the stage, the difference between
changing service files themselves to indicate enabled/disabled status
and adding/removing relevant lines to inittab becomes more and more
vague.


Considerations for initdir entries format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Should initdir entries like /etc/rc/httpd be executable?
It can help debugging things, that is, allow running

	/etc/rc/httpd

manually to check why the damn thing refuses to start properly.

On the other hand, putting too much effort into executability
does not look like a good idea. After all, these are primarily
init configuration files.

In the end, the decision was to keep them executable, leaving
shebang line as is and placing command in non-shebang files
on a separate line.

Another key point is allowing comments in all inidir files.
With shell scripts, it's easy, but in non-shebang files
comments do not fit naturally.

Alternative considered:

	#:123!/bin/sh
	# shell script follows

	#:123:/sbin/httpd

this would allow laying initrec out in one line just like in inittab.
However, files like this would probably require an utility for test runs.
